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1. Real Party in Interest 

This apphcation is assigned to Phihps Electronics North America Corporation, the 
real party in interest. 

2. Related Appeals and Interferences 

There are no other appeals or interferences that would directly affect, be directly 
affected, or have a bearing on the instant appeal. 



3. Status of the Claims 

Claims 1-15 have been rejected in the Final Office Action. The final rejection of 
claims 1-15 is being appealed. 



4. Status of Amendments 

All amendments submitted by Appellants have been entered. 



5. Summary of Claimed Subject Matter 

The present invention, as recited in independent claim 1, is directed to a system 
for sending out-of-band (OOB) service information from a service provider comprising a point 
of deployment (POD), the construction of out-of-band (OOB) transport stream (TS) packets, the 
insertion of said packets, and a set-top box. (See Specification p. 4 11. 3-5; p. 6 11. 14-17; Fig. 1). 
The POD module receives an in-band (IB) TS including IB TS packets. (See Specification p. 8 
11. 15-19; Fig. 2). The POD module also includes a processor for processing OOB service 
information from a service provider. The construction of OOB TS packets is done using OOB 
service information, and identifying unoccupied gaps in the IB TS, and inserting said packets 
into the unoccupied gaps of the IB TS. The OOB and IB packets are then sent to the set-top box 
to be processed using a TS channel. (See Specification p. 9, 11. 13-23; Fig. 2). 

The present invention, as recited in independent claim 4, is directed to a method 
of sending OOB service information from a service provider between a data module (12) and a 
host device (10). (See Specification p. 7, 11. 2-6; Fig. 1). The method includes first receiving an 
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IB TS at a data module (12), followed by receiving OOB service information. The OOB TS is 
then constructed using OOB service information and identifying unoccupied gaps in the IB TS. 
Once the gaps are identified, OOB are inserted into the unoccupied gaps and the packets are then 
sent to a host device (10). (See Specification p. 9, II. 13-23; Fig. 2) 

The present invention, as recited in independent claim 7, is directed to a data 
module (12) for use with a host device (10), said data module (12) receiving an IB TS including 
IB packets. (See Specification p. 7, 11. 2-6; Fig. 1). The data module (12) comprises a processor 
(1 8) for processing OOB service information, constructing OOB TS packets using the OOB 
service information. (See Specification p. 6, 11. 6-7; Fig. 1). The data module (12) identifies 
unoccupied gaps in the IB TS and inserts the OOB packets into the unoccupied gaps creating a 
single TS, which is sent to a host device (10). (See Specification p. 9, II. 13-23; Fig. 2) 

The present invention, as recited in independent claim 12, is directed to a host 
device (10) comprising a processor (26) for processing OOB service information. The OOB 
service information is received from the OOB TS packets sent by a data module in the 
unoccupied gaps in an IB TS. (See Specification p. 9, 11. 13-23; Fig. 2) 

6. Grounds of Reiection to be Reviewe d on Appeal 

I. Whether claims 1-15 are unpatentable under 35 U.S.C. § 103(a) over U.S. 
Pat. No. 6,628,891 to Vantalon et al. (hereinafter "Vantalon") in view of U.S. Pat. Pub. No. 
20030103532 to Bertram et al. (hereinafter "Bertram") in further view of U.S. Pat, Pub. No, 
20020101991 to Bacon et al. (hereinafter "Bacon"). 
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7. Argument 

I. The Rejection of Claims 1-15 Under 35 U.S.C. § 103(a) Over Vantalon in view of 
Bertram in further view of Bacon Should Be Reversed. 

A. The Examiner's Rejection 

In the Final Office Action, the Examiner rejected claims 1-15 under 35 U.S.C. § 
103(a) as being unpatentable over Vantalon in view of Bertram in further view of Bacon. (See 
02/23/07 Office Action, p. 2). 

Vantalon is directed toward conditional access method and apparatus that are 
provided for use with digital television receivers and other digital broadband receivers. The 
methods and apparatus are capable of handling several different signal transmission protocols in 
an automatic flexible manner. An input unit is utilized to analyze and tag incoming data bytes so 
that further processing operations are less dependent on the transmission format being received. 
A cipher unit is utilized to adapt, in real time, the scrambling and descrambling performances to 
match the requirements of the transmission network and the receiving apparatus. A filtering 
mechanism is utilized to filer and handle multiple asynchronous data streams in a parallel 
manner. (See Vantalon Abstract). 

Bertam is directed toward a method and apparatus for transporting encoding asset 
data and content data. The transport encoded content data gets multiplexed with a plurality of 
NULL transport packets to provide a "place holder" for asset data transport packets, and 
replacing the NULL transport packets with asset data transport packets prior to transmitting the 
multiplexed transport stream to a set top box. (See Bertram Abstract). 

Bacon is directed a subscriber television system with a host terminal. The system 
allows for the identification of individual packets from two separate MPEG transport streams 
that have been multiplexed together for decoding by a single external condition access or point- 
of-deployment (POD). The decoding of two separate MPEG transport streams allows for the use 
of multiple tuner host terminals for such function as picture-in-picture (PIP) or the recording of 
one program while watching another program. (See Bacon Abstract). 
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B. The Cited Patents Do Not Disclose Inserting The OOB TS Packets In The 
Unoccupied Gaps And Sending The OOB TS Packets And The IB TS 
Packets To A Set-Top Box Using A Transport Stream Channel, As 
Recited In Claim 1 . 

Claim 1 recites, "inserting the OOB TS packets in the unoccupied gaps and 
sending the OOB TS packets and the IB TS packets to a set-top box using a transport stream 
channel." The Examiner asserts that this recitation of claim 1 is disclosed in Bertram. (See 
2/23/07 Office Action, p. 3). Appellants respectfully disagree. 

The Examiner asserts that "inserting the OOB TS packets in the unoccupied gaps 
and sending the OOB TS packets and the IB TS packets to a set-top box using a transport stream 
channel," as recited in claim 1 , is met by the placing of NULL packets in the content stream as a 
place holder for the insertion of asset packets as described in Bertram. However, the reservation 
of space inside the content stream by a NULL packet is not the same as the insertion of OOB 
packets when the system detects a gap in the IB TS. In Bertram, the system specifies areas 
within the transport stream where it wants to place asset packets. (See Bertram par. [0042]). 
When an area is identified, it places a NULL packet within the data stream. This reserves a spot 
in the data stream and prevents any content packets from being transmitted in that space. The 
system then replaces the NULL packets with asset packets to be transmitted along the data 
stream. In Bertram, once a NULL packet has been placed, a content packet cannot be placed in 
the same space, even if an asset packet has not been placed there yet. (See Bertram par. [0024]). 
In contrast, claim 1 recites inserting OOB packets in an empty space unoccupied by an IB 
packet. Thus, an IB packet can be placed in the unoccupied gaps at any time up until an OOB 
packet is placed in the unoccupied gap. The unoccupied gap is not reserved, while the empty 
space is reserved by a NULL packet in Bertram. 

The Examiner also equates a NULL packet being placed inside the transport 
stream, as described in Bertram, to the "identifying unoccupied gaps in the IB TS," as recited in 
the claim 1. These, however, are not the same. When a packet is transmitted from one 
destination to another, the packet contains two types of information. The first type of 
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information is the information required for the packet to know its starting point and its 
destination, usually called the header. The second type of information is the payload, or actual 
information used at the destination, such as video information. Those skilled in the art will 
understand that a NULL packet contains the header information, but does not have a payload. 
"A NULL packet is a particular undeclared transport packet that belongs to nobody. Its payload 
is undefined." (See Leonardo Chiariglione, MPEG Systems FAQ, p. 6 of 7 (last modified Aug. 
27, 2006) http;//www.chiariglione.org/MPEG/i^q/mp2-sys/mp2-sys.htm. Printout attached 
hereto in the Evidence Appendix). So for the system in Bertram to reserve a packet of X bits it 
must create a NULL packet, having a size of X bits to reserve the space in the transport stream. 
Thus, in the system of Bertram, there are physical packets occupying a location in the data 
stream before an asset packet is inserted. So, while the NULL packet may not contain any data 
readable by the receiving device, it still must contain data to reserve the necessary space for the 
latter insertion of the asset packet(s). That is a NULL packet is not an unoccupied gap in the 
data stream. 

In contrast, claim 1 specifically recites, "identifying unoccupied gaps in the IB 
TS, inserting the OOB TS packets in the unoccupied gaps." In Bertram, however, an asset 
packet is placed in a space where a NULL packet is located. (See Bertram par. [0042]). These 
two methods of inserting packets inside of a data stream are different. The system in Bertram 
does not have the ability to place an asset packet inside of an empty space. The system can only 
place an asset packet in a space already occupied by a NULL packet. Thus, Appellants 
respectfiilly submit that Bertram does not teach or suggest, "inserting the OOB TS packets in the 
unoccupied gaps and sending the OOB TS packets and the IB TS packets to a set-top box using a 
transport stream channel," as recited in claim 1. Accordingly, Appellants respectfully request 
that the Board overturn the Examiner's rejection of claim 1 . Because claims 2 and 3 depend 
from and, therefore, include all the limitations of claim 1, it is respectfully submitted that these 
claims are also allowable. 

Independent claim 4 recites "idenfifying unoccupied gaps in the IB TS; inserting 
at least one of the OOB TS packets into the unoccupied gap." Appellants respectfully submit 
that this claim is allowable for at least the same reasons stated above with reference to claim I 
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and the Board should overturn the Examiner's rejection of this claim. Because claims 5, 6 and 
15 depend from and, therefore, include all the limitations of claim 4, it is respectfully submitted 
that these claims are also allowable. 

Independent claim 7 recites, "identifying unoccupied gaps in the IB TS, inserting 
the OOB TS packets in the unoccupied gaps and sending the OOB TS packets and IB TS packets 
to a host device using a transport stream channel." Appellants respectfully submit that this claim 
is allowable for at least the same reasons stated above with reference to claim 1 and the Board 
should overturn the Examiner's rejection of this claim. Because claims 8-1 1 depend from and, 
therefore, include all the limitations of claim 7, it is respectfully submitted that these claims are 
also allowable. 

Independent claim 12 recites, "wherein the OOB service information is received 
from OOB transport stream (TS) packets sent by a data module in unoccupied gaps in an IB TS." 
Appellants respectfully submit that this claim is allowable for at least the same reasons stated 
above with reference to claim 1 and the Board should overturn the Examiner's rejection of this 
claim. Because claims 13 and 14 depend from and, therefore, include all the limitations of claim 
12, it is respectfully submitted that these claims are also allowable. 
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Conclusion 



For the reasons set forth above, Appellants respectfully request that the Board 



reverse the rejection of the claims by the Examiner under 35 U.S.C. § 103(a), and indicate that 
claims 1-15 are allowable. 

Please direct all future correspondence to: 



Larry Liberchuk, Esq. 
IP Counsel 

Philips Intellectual Property & Standards 
P.O. Box 3001 

Briarcliff Manor, NY 10510-8001 

Phone: (914) 333-9618 

Fax: (914) 332-0615 

Email: larry. liberchuk @philips.com 



Respectfully submitted, 





Fay Kaplun & Marcir/LLP 
150 Broadway, Suite 702 



New York, NY 10038 
Tel: (212) 619-6000 
Fax:(212) 619-0276 
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CLAIMS APPENDIX 

1 . (Previously Presented) A system for sending out-of-band (OOB) service information from a 
service provider, the system comprising: 

a point of deployment (POD) module which receives an in-band (IB) transport stream 
(TS) including IB TS packets, the POD module including a processor for processing OOB 
service information from a service provider, constructing OOB TS packets using the OOB 
service information, identifying unoccupied gaps in the IB TS, inserting the OOB TS packets in 
the unoccupied gaps and sending the OOB TS packets and the IB TS packets to a set-top box 
using a transport stream channel; and 

wherein the set-top box includes a processor for processing the OOB TS packets. 

2. (Original) The system of claim 1, wherein the point of deployment module further includes a 
buffer for storing the OOB TS packets. 

3. (Previously Presented) The System of claim 2, wherein the point of deployment module sends 
the OOB TS packets between two consecutive IB TS packets of the IB TS without delaying the 
two consecutive IB TS packets. 

4. (Previously Presented) A method of sending out-of-band (OOB) service information from a 
service provider between a data module and a host device, the method comprising the steps of: 

receiving an in-band (IB) transport stream at a data module; 
receiving out-of-band service information at the data module; 

constructing OOB transport stream (TS) packets using the OOB service information; 
identifying unoccupied gaps in the IB TS; 

inserting at least one of the OOB TS packets into the unoccupied gap; and 
receiving the OOB TS packets at a host device. 

5. (Original) The method of claim 4, wherein the data module is a point of deployment module. 

6. (Previously presented) The method of claim 4, wherein the host device is a set-top box. 
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7. (Previously Presented) A data module for use with a host device, the data module receiving 
an in-band (IB) transport stream (TS) including IB TS packets, the data module comprising: 

a processor for processing out-of-band (OOB) service information, constructing OOB TS 
packets using the OOB service information, identifying unoccupied gaps in the IB TS, inserting 
the OOB TS packets in the unoccupied gaps and sending the OOB TS packets and IB TS packets 
to a host device using a transport stream channel. 

8. (Original) The data module of claim 7, further including a buffer for storing the OOB TS 
packets. 

9. (Previously Presented) The data module of claim 8, wherein the data module sends the OOB 
TS packets between two consecutive IB TS packets the IB TS without delaying the two 
consecutive IB TS packets. 

10. (Previously presented) The data module of claim 7, wherein the data module is selected fi:om 
the group consisting of a point of deployment module, a wireless data interface appliance, a 
smartcard, a personal computer and an internet interface appliance. 

1 1 . (Original) The data module of claim 7, wherein the host device is a set-top box. 

12. (Previously Presented) A host device for use with a data module, the host comprising: 

a processor for processing out-of-band (OOB) service information, wherein the OOB 
service information is received from OOB transport stream (TS) packets sent by a data module in 
unoccupied gaps in an in-band TS. 

13. (Original) The host device of claim 12, wherein the host is a set-top box. 

14. (Previously Presented) The host device of claim 13, wherein the processor is further adapted 
for receiving the OOB TS packets between two consecutive transport stream packets of the in- 
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band TS, wherein the two consecutive transport stream packets are not delayed from their 
original timing by the OOB TS packets. 

15. (Previously presented) The method of claim 4, further comprising the step of buffering the 
OOB TS packets. 
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EVIDENCE APPENDIX 

Leonardo Chiariglione, MPEG Systems FAQ (last modified Aug. 27, 2006) 
http://www.chiariglione.org/MPEG/faq/mp2-sys/mp2-sys.htm, attached hereto, 6 of 7 pages 
printed on 07/18/07. 
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RELATED PROCEEDING APPENDIX 

No decisions have been rendered regarding the present appeal or any proceedings 

related thereto. 



13 



MPEG Systems FAQ 



Page 1 of 7 



MPEG-2 Systems 

1. What is MPEG-2 Systems? 
2..WMdevdopMlliis.sia^^^ 

I. WMdljMustries hMfiMop^^^^^ 
4..WMdlJtandardbiid^^^^ 

5. Why do I need to be MPEG-2 Systems compliant? 

6..Is.ih£re..a.referenc^.implmiei^^^^ 

Z.Mialm\lhe..differentMPEG-2.%slems.mmpme^^^^^^ 

8. What is the difference between MPEG-1 Systems and MPEG-2 Systems? 

9. What is the difference between an MPEG-1 Systems stream and an MPEG-2 Systems 
Program stream? 

1 0. Is the MPEG-2 Transport Stream a transport multiplex? 

I I. What is carried in MPEG-2 Transport Streams? 
.12..A¥hy..are.Transpnrt.p.ack^^^ 

13. What about the programs carried within the MPEG-2 Transport Stream? 

14. Why do so many application use MPEG-2? 

15. What is the main assumption made by MPEG-2 Systems? 

16. What is a syntax? 

17. What is a time stamp ? 

18. Are time stamps mandatory? 

1 9. Where are the PTSs and DTSs inserted? 

20. What is PSI-^ 
21..WhatisJhe diffeimc.e^^^ 
22..1¥hatMILM£QiinilmbMdMiiLaJE^^^ 
23...What.MIh£.fQmid.inP5.l5£aiQMZ 

24. Did MPEG-2 do research on Conditional Access methods? 

25. Why is PSI information not synchronised? 

26. Why is Video or Audio material not protected at MPEG-2 systems level? 

27. Is the MPEG-2 transport stream a two or a three level multiplex? 

28. Is the MPEG-2 program stream a two or a three level multiplex? 

29. What is the use of NULL packets? 
30J.sJlie.Mtiitre.amj:ate..^^^^^ 

3 1 . How do DVB and ATSC use MPEG-2 transport? 

32. Are there any error detection mechanisms? 

33. What is a system target decoder model? 

34. Why have the STD models been invented? 

35. What are the constraints imposed by the T-STD model? 

1. What is MPEG-2 Systems? 

MPEG-2 Systems is an ISO/IEC standard (13818-1) that defines the syntax and semantics of 
bitstreams in which digital audio and visual data are multiplexed. Such bitstreams are said to 
be MPEG-2 Systems compliant. This specification does not mandate, however, how 
equipment that produces, transmits, or decodes such bitstreams should be designed. As a 
result, the specification can be used in a diverse array of environments, including local 
storage, broadcast (terrestrial and satellite), as well as interactive environments. 

2. Who developed this standard? 
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This standard was industry driven, and complemented the MPEG-2 activities in audio and 
video coding. The consumer TV industry actively participated in the definition of MPEG-2 
Systems, to ensure that a low-complexity receiver can be built at a reasonable cost. 

3. Which industries have adopted this standard? 

The list is extensive and continuously growing: consumer TV (cable, satellite and terrestrial 
broadcast). Video on Demand, Digital Video Disc, personal computing, card payment, test 
and measurement, etc. 

4. Which standard bodies have adopted this standard? 

In Europe, DVB (Digital Video Broadcast). In the USA, FCC (Federal Communications 
Commission), ATSC, SCTE. In Japan, MITI/JISC. The DAVIC consortium. DVD. 

5. Why do I need to be MPEG-2 Systems compliant? 

In the design of equipment, you have to be MPEG-2 Systems compliant for several reasons. 
First, if your equipment has to be compliant with DVB, FCC, JISC, ATSC, SCTE, DVD, or 
DAVIC requirements, as these bodies require MPEG-2 Systems compliance. Secondly, 
because your design can rely on Integrated Circuits developed in that area. Finally, your 
application will be opened to all the MPEG-2 Systems world, and will be usable over a large 
number of networks. The MPEG-2 Systems standard enables the widest interoperability in 
digital video and audio applications and services. 

6. Is there a reference implementation? 

Yes, reference bitstreams are described in the MPEG-2 document TR 13813-5. 

7. What are the different MPEG-2 Systems components? 

MPEG-2 Systems provides a two layer multiplexing approach. The first layer is dedicated to 
ensure tight synchronisation between video and audio. It is a common way for presenting all 
the different materials which require synchronisation (video, audio, and private data). This 
layer is called Packetized Elementary Stream (PES). The second layer is dependent on the 
intended communication medium. The specification for error free environments such as local 
storage is called MPEG-2 Program Stream, while the specification addressing error prone 
environments is called MPEG-2 Transport Stream. 

8. What is the difference between MPEG-1 Systems and MPEG-2 Systems? 

MPEG-2 Systems mandated compatibility with MPEG-1 Systems. The MPEG-2 Program 
Stream is designed for that purpose. MPEG-2 Systems also addresses error prone 
environments, and provides all the hooks for Conditional Access systems. 

9. What is the difference between an MPEG-1 Systems stream and an MPEG-2 Systems 
Program stream? 

The major difference lies on the signalling which is present in MPEG-2 Program Streams 
and was absent in MPEG-1 Systems. A minor difference also exists in the PES format. 
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10. Is the MPEG-2 Transport Stream a transport multiplex? 

No, MPEG-2 transport is rather a service multiplex. No mechanism, within the syntax, exists 
to ensure the reliable delivery of the transported data. MPEG-2 transport relies on underlying 
layers for such services. MPEG-2 transport requires the underlying layer to identify the 
transport packets and to indicate in the transport packet header, when a transport packet has 
been erroneously transmitted. The MPEG-2 Transport Stream is so named to signify that it is 
the input to the Transport layer in the OSI seven layer network model. It is not, in itself, the 
Transport layer. 

11. What is carried in MPEG-2 Transport Streams? 

MPEG-2 Transport Streams carry transport packets. These packets carry two types of 
information: the compressed material and the associated signalling tables. A transport packet 
is identified by its PID (Packet Identifier). Each PID is assigned to carry data belonging 
either to one particular compressed data source (and only this data source) or one particular 
signalling table. The ordered sequence of packets with a given PID may be considered as one 
data stream. The compressed data source may be derived from either video, audio or data 
elementary streams. These elementary streams may be tightly synchronized (as it is usually 
necessary for Digital TV programs, or for Digital Radio programs), or not synchronised (in 
the case of programs offering downloading of software or games, as an example). 

The associated signalling tables consist of the description of the elementary streams which 
are combined to build programs, and in the description of those programs. Tables are carried 
in sections. The signalling tables are called PSI (Program Specific Information). 

12. Why are Transport packets 188 bytes long? 

Because MPEG-2 wanted these packets to be carried over ATM. At that time, according to 
the AAL which was envisaged, ATM cells were supposed to have a payload of 47 bytes. 

188 = 4 * 47. 

13. What about the programs carried within the MPEG-2 Transport Stream? 

There is a description of each program carried within the MPEG-2 Transport Stream. This 
description usually requires a particular table, the Program Map Table, with one table per 
program. This table is only sent periodically. On the other hand, the elementary streams 
which make up a program are continuously carried in PES streams. In that sense it could be 
said that an MPEG-2 Transport Stream does not carry programs, but only carries elementary 
streams and the instructions required to associate particular elementary streams into 
particular programs. 

14. Why do so many application use MPEG-2? 

One of the attractive aspects of MPEG-2 comes from its fundamental requirement to be 
generic. 

Another reason is that in all the syntax and signalling provisions are made to allow 
applications to develop their own private syntaxes and signalling. A lot of private needs may 
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be satisfied. 

15. What is the main assumption made by MPEG-2 Systems? 

That the network is ideal, and that each byte is transmitted with a constant delay. 

16. What is a syntax? 

Generally speaking, a syntax specifies the structure of a bitstream: how different parameters, 
tags, etc., are mapped and laid out on the bitstream. For multiplexing purposes, it is 
important for the syntax to provide patterns which can be recognized with an extremely high 
degree of confidence. These patterns are called synchronisation patterns. In addition, an 
indication of time and of the bit rate of the bitstream may also be provided. 

Equipped with such elements, a bitstream corresponding to an MPEG-2 syntax is a self 
contained bitstream on which a receiver can slave itself, in order to acquire that bitstream 
exactly synchronised with the production of that bitstream. However, time indication and bit 
rate indication are not mandatory. 

17. What is a time stamp? 

They are two types of time stamps: 

• The first type is usually called a reference time stamp. This time stamp is the 
indication of time mentioned in the previous question. Reference time stamps are to be 
found in the PES syntax (ESCR), in the program syntax (SCR), and in the transport 
syntax (PCR). 

• The second type of time stamp is called DTS (Decoding Time Stamp) or PTS 
(Presentation Time Stamp). They indicate the exact moment where a video frame or an 
audio frame has to be decoded or presented to the user respectively. 

18. Are time stamps mandatory? 

No, they are not mandatory. Some applications like Digital TV broadcast, where tight 
synchronisation is required, will make an extensive use of time stamps. In that case both 
reference time stamp and DTS/PTS are used. In other cases (game or software downloading 
for example) neither reference nor DTS/PTS time stamps are necessary. DTS and PTS time 
stamps are not relevant if reference time stamps are not present. 

19. Where are the PTSs and DTSs inserted? 

They are inserted as close as possible to the portions of compressed video, audio, or data to 
which they apply. Precisely, this means that they are inserted in the PES packet headers, a 
syntax which is common to all data sources. 

20. What is PSI? 

PSI (Program Specific Information) carries the signalling. PSI has no synchronisation pattern 
in the section headers. 
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21. What is the difference between a PES packet and a PSI section? 

A PES packet is a way to uniformly packetize elementary streams. Embedded in PES 
packets, elementary streams may be synchronized with time stamps. They are not protected. 
The PES packets may be of variable length, which allows them to be also of fixed length. 
PES packets may be rather long packets. As elementary streams are continuous streams, it is 
also possible to know that a PES packet is finished because the next PES packet arrives. 
Therefore, sometimes a length indication is not even relevant (for video PES packets). 

A PSI section is a way to carry a portion of a PSI table. A PSI section is a way to uniformly 
represent signalling. PSI sections are not synchronized. They may be protected by a CRC. 
The sections are of a variable length. They are rather small. The length is always relevant. It 
is the only mechanism to go from one section to the next section when they are carried in the 
same packet. An update mechanism is also supported which allows association of a version 
number to a section. 

22. What will be found embedded in a PES packet? 

Continuous streams are to be found within the PES packets: They consist of either video, 
audio or data material. The video may be of different kinds (MPEG-1, MPEG -2), and the 
same for audio. There is no assumption about elementary data streams. One of the first uses 
is for subtitling. 

23. What will be found in PSI sections? 

Signalling is carried in PSI sections. Conditional Access messages are usually also carried in 
PSI sections. Downloading of data will almost certainly use the PSI section mechanism. 

24. Did MPEG-2 do research on Conditional Access methods? 

MPEG -2 only provided hooks for the Conditional Access systems: 

• the means to carry the messages (key words in ECMs, and entitlement in EMMs), 

• and the means to declare them (in PSI tables, in Transport packet headers, and in PES 
headers). The syntax of the messages is determined by each particular Conditional 
Access system. 

25. Why is PSI information not synchronised? 

Because tight synchronisation between signalling and elementary streams was not required. 
It is enough, generally speaking, to signal an event a little in advance. In some cases, 
however, that makes dynamic changes quite tricky, especially when elementary streams are 
scrambled, or when a program changes from an "in the clear" state to a scrambled state. 

26. Why is Video or Audio material not protected at MPEG-2 systems level? 

The error concealment techniques are implemented within the audio and the video layers. 
For error protection MPEG-2 Systems relies on the underlying layer to deliver transport 
packets with a BER rate around 10-10. 
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27. Is the MPEG-2 transport stream a two or a three level multiplex? 

It is a two layer multiplex, as the pure audio and video material are first packetized in PES 
packets and secondly packetized in transport packets. Transport packets are multiplexed. It is 
not a three level multiplex as there is no packetization related to programs. 

28. Is the MPEG-2 program stream a two or a three level multiplex? 

It is a one layer multiplex, as the pure audio and video material are only packetized in PES 
packets. PES packets are then multiplexed. It is not a two level multiplex as there is no 
packetization related to the carried program. 

29. What is the use of NULL packets? 

They are usually used as a provision for rate stuffing in order to avoid the bottleneck of 
insufficient resources. Usually transport packets have to be declared in the PSI information 
tables. A NULL packet is a particular undeclared transport packet that belongs to nobody. Its 
payload is undefined. Some applications use NULL packets in order to insure a good and 
quick synchronization mechanism, as their modulation scheme is not aligned on the start of 
transport packets. 

30. Is the bitstream rate always explicitly carried? 

Yes for the PES syntax and the MPEG-2 program syntax. 

No for the MPEG-2 transport syntax. For that syntax, the transport rate may appear in the 
PSI information. 

31. How do DVB and ATSC use MPEG-2 transport? 

In defining their own operational rules and implementation guidelines. They specified also 
their own signalling (Service Information) using the already defined MPEG-2 private 
sections. Modulation schemes adapted to satellite, to cable and to terrestrial broadcast have 
been adopted. Physical interfaces between equipment have been specified. Parameters, 
relevant for real -time and offline measurements, have been specified. 

32. Are there any error detection mechanisms? 

Two CRCs are to be found: 

• one in the PES syntax, but its purpose is to check the error robustness of a network 
link. It is a CRC calculated over the previous transmitted PES packet. 

• The second in the PSI information. It is a way to ensure that a section has not been 
corrupted. 

That is why sections have to be short, in order for the CRC to be efficient. 

33. What is a system target decoder model? 

A system target decoder (STD) model is a virtual decoder. There are two models, one within 
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the MPEG-2 program syntax (the P-STD), the other within the MPEG-2 transport syntax 
(The T-STD). A model defines buffer sizes, their input and output rates, and timing 
constraints related to time stamps values. 

34. Why have the STD models been invented? 

Not to be implementation dependent. The first model comes from MPEG-1 Systems. Some 
of the assumptions in the T-STD are even not realistic at all: buffers, for instance, when 
decoding occurs are supposed to be emptied instantaneously. 

35. What are the constraints imposed by the T-STD model? 

They apply to different elements: 

• Timing information: 

if the time stamps (PTS, DTS) are wrong the elementary stream buffers may 
underfiow or overflow. 

• Multiplex scheduling: 

If there are too many consecutive packets of the same elementary stream in a transport 
stream buffers will overflow. 

• Constraints on the manipulation of MPEG-2 transport streams: 

The T-STD specifies the bounds within which remultiplexing of a transport stream is 
possible. 
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